This
section covers available topologies, Microsoft-approved assumptions,
server roles, and a simplified scenario that provides you with an
example of how you could scale out a farm.
SharePoint 2010 topologies can be broken into a limited deployment farm, small farm, medium farm, and large
farm. These topologies allow SharePoint 2010 to be deployed on a single
server or on many servers. SharePoint 2010 is designed to be scaled out
using a three-tier system for its server roles, using server groups to
build out your farm.
Note:
This section does not cover the large farm topology. A large farm is just a medium farm topology in which Search functionality is in a separate farm and the remaining servers are grouped by function.
Topologies and scaling
are closely associated: you must understand your topology to be able to
scale efficiently and accommodate different scenarios and organizational
requirements. The following are some best practices to use when scaling
out your farms.
1. Server Roles
As part of managing a server
farm, you need to understand the basic roles that various servers
perform in your farm. The following sections introduce you to the roles
of the Web server, application servers, and database servers.
1.1. Web Server
A Web server is used to host
Web pages, Web services, and Web Parts that are necessary to process
requests served by the farm. A Web server directs requests to the
appropriate application server. This is a necessary role for farms that
include other SharePoint 2010 capabilities. In dedicated search service
farms, this role is not necessary, because Web servers at remote farms
contact query servers directly. In small farms, this role can be shared
on a server with the query role.
When working with
SharePoint, users connect only to the Web server—they do not connect
directly to an application or database server. This is why the Web
server is the most heavily utilized server in your farm. Client calls go
in and out of the Web server, and that can represent a significant load
during peak usage.
1.2. Application Server
Application server roles
are associated with services that can be deployed to a physical
computer. Each service represents a separate application service that
can potentially reside on a dedicated application server. You can group
services with similar usage and performance characteristics on a server,
and you can scale out services onto multiple servers together. For
example, client-related services can be combined into a service group.
After deployment, look for services that consume a disproportionate
amount of resources and consider placing these services on dedicated
hardware when you decide to scale out your services and farms.
1.3. Database Server
In a small-farm
environment, all databases can be deployed to a single server. In larger
environments, group databases by roles and deploy these to multiple
database servers. You might want to group and scale out Search and
content databases to their own servers starting as early as the small
farm, depending on usage requirements.
2. Scaling Out a Farm with Server Groups
The number of
services and corresponding databases in SharePoint 2010 is greater than
in the previous SharePoint Server 2007 releases. The recommendation for
scaling out a farm is to group services or databases with similar
performance characteristics onto dedicated servers and then scale out
the servers as a group. This group is not enforced in the SharePoint
Central Administration interface but instead is a logical group that you
create on paper as you build out your farm.
For example, group all Search-related services onto one or two servers
and then add servers to this group as needed to satisfy user demand for
these services. In some cases, you might need to create a dedicated
server group for a single service, such as Search or PerformancePoint
services.
Combine service
applications and related components (for example, databases) into
several different logical groupings that can be used as a starting
point; for scaling
in large environments, the specific server group that evolves for a
farm depends on the specific demands for each service.
Note:
Remember that a server group is a planning concept—you will not find this term or concept in SharePoint Central Administration.
The remainder of
this article introduces a scenario involving a company called Contoso
Pharmaceutical, to provide you with an example of how the process of
scaling out a farm can work. This company started out small, making only
one product, then grew to a midsize company with several hundred
products. The company’s SharePoint farm also grew to accommodate Contoso
Pharmaceutical’s physical growth.
2.1. Contoso Pharmaceutical Small Farm Topologies
The IT department at
Contoso Pharmaceutical installed a single farm SharePoint 2010 as a
proof of concept. Most companies, when first deploying SharePoint 2010,
take the single farm, single group approach. This is the default
settings, and thus all the services are deployed in one default group.
Even when using a small
farm topology, however, the deployment has room to grow from a two-tier
to a three-tier approach, as you can see in the following examples.
2.1.1. Description of the two-Tier Approach
When Contoso
Pharmaceutical deployed SharePoint 2010 originally, all services were
activated within the default group of services used for all Web
applications in a farm. All sites had access to all of the service
applications deployed in the farm. Contoso deployed a two-tier approach,
with a Web tier and a database tier, as shown in Figure 1.
Eventually, several
department-wide collaborative initiatives created more of a demand for
SharePoint 2010 within the corporate environment as well as more
end-user adoption. These initiatives used services such as Excel
Services, Access Services, and Search Services, which increased demand
on the two-tier farm. As performance decreased due to this increase in
usage, it was time to scale out this farm.
2.1.2. Description of the three-Tier Approach
Increased demand for application services and more end-user usage meant Contoso needed to separate the WFE and application server
roles. In doing so, the farm was scaled out successfully to a
three-tier configuration, with the query service remaining in the Web
tier layer, but with a new dedicated application server providing
services to all the departments within the enterprise. Figure 2 provides a view of this configuration with the newest server shown in the middle tier.
Contoso took advantage of some
key factors in moving into this new configuration. This provides the
simplest architecture, with no server
sharing roles. All the services on this farm are available to all Web
applications, and this is the most efficient use of the farm’s
resources. Lastly, all of the service applications are managed
centrally.
This environment does have a
couple of disadvantages, however. It does not allow for the isolation of
service data, and no departments or groups have been given permissions
to manage their own isolated service applications.
2.1.3. Recommendations
This is the recommended
configuration for most companies, at least initially. This
configuration works well for hosting a large number of sites for a
single company on the same farm and provides well for a limited number
of intranet deployments and collaboration initiatives.
Note:
Use this configuration if
you want to optimize the resources required to run services within a
farm or you want to share content and profile data across sites that
otherwise require process isolation for performance or security reasons.
|
A small farm environment can consist of three servers:
one Web front-end server, one Web front-end/application server, and one
database server. Although this configuration is successful, it is also
limited—it can handle up to 20,000 users. If your farm should have a
mission critical application, you are faced with having no redundancy
and additional points of failure in your design.
Points of failure include a
single database server and a single server housing the service
applications. This may be adequate to fulfill your business
requirements, but if one of those boxes goes down, you will lose either
your farm environment or that service application. If the service
application is a cross-farm service being consumed by another farm, you
now have a loss of functionality on not just one farm but on two farms.
Having one service
application server is fine, depending on your usage demands, but if you
have search requirements, you should think about scaling
out that service to multiple servers to provide redundancy to your
partitioned index and Search service. You already have redundancy with
your query service because it is residing on your WFE.
This real world example
would be suitable for a remote location using local services and
consuming cross-farm services from a remote farm elsewhere.
|
2.2. Contoso Medium Farm Topology
Several years later, Contoso
has become a midsize company with over 20,000 users and 30 terabytes of
data in their SharePoint databases. The company’s enterprise search
requirements have increased, both in frequency of use by end users and
in the size of the index. They are now handling more than 30 million
documents.
2.2.1. Description
At this point, Contoso
has optimized their farm to accommodate the large number of documents
and the associated increased search and indexing requirements.
Departments and divisions also have isolated service applications
serving them.
Contoso can keep
performance from declining by using dedicated application servers to
handle query and crawling during searches. This approach is also useful
because you can break off the index to have multiple fault-tolerant
partitions. Departments can now isolate their service data, which will
allow them to remain compliant with various regulations.
2.2.2. Recommendations
This configuration works
well for companies that require services to be isolated, whether for
security or performance reasons. It also allows those services to be
consumed enterprise wide. This configuration is optimized with Search in
mind, as Figure 3 shows.
|
For an enterprise-level
organization, a medium farm may not be big enough to handle the
increased demands on SharePoint, and you might find that you need to
scale out even more into a large-scale farm configuration.
The majority of
production SharePoint environments will not reach this size, however.
Recommended best practice is to continue grouping services and databases
with similar performance characteristics onto dedicated servers and
then scale out those servers into server groups. Figure 4 illustrates a practical example of this concept.
In this example, the Web
tier consists of redundant WFE and Administration. The application tier
breaks crawl and query into separate groups and also includes a sandbox
code group. All other services are grouped together. Finally, on the
database tier, search databases and content databases are clustered and
grouped. All other databases are clustered on their own groups.
In this example, Search is
included in the database tier; however, it is a recommended practice to
break out Search at this level to its own farm. This recommended
practice can be applied to all other cross-farm services. Scaling out a
SharePoint 2010 environment is always dependent on the requirements and
goals of your organization.
|
